SD-3343

I was unable to run the ecma-spec MCP lookups — every call returned "haven't granted it yet" (permission was declined in this session), so I'm reviewing against ECMA-376 §20.4.2 (DrawingML — WordprocessingDrawing) from spec knowledge rather than live tool confirmation. Flagging that up front per the faithful-reporting bar.

Status: PASS

The handler change (encode-image-node-helpers.js) only ever reads distT/distB/distL/distR off the wp:anchor node (lines 167–172) and merges them into the internal wrap model when the wrap child omitted them. All four of those attributes are legitimately defined on CT_Anchor, so no non-existent attribute is read, nothing required is dropped, and the "absent → use anchor value, skip if zero" defaulting is reasonable. No spec violation in the import path. See https://ooxml.dev/spec?q=anchor.

One nuance worth recording, though it isn't a hard violation in this diff:

• mergeAnchorPaddingIntoWrapDistances is applied uniformly to Square, Tight, Through, and TopAndBottom (encode-image-node-helpers.js:290–292), merging all four sides. But per spec the wrap elements don't all carry all four distances:

  • wp:wrapTight / wp:wrapThrough (CT_WrapTight/CT_WrapThrough) define only distL/distR — no top/bottom. (https://ooxml.dev/spec?q=wrapTight)
  • wp:wrapTopAndBottom (CT_WrapTopBottom) defines only distT/distB — no left/right. (https://ooxml.dev/spec?q=wrapTopAndBottom)
  • wp:wrapSquare carries all four. (https://ooxml.dev/spec?q=wrapSquare)

  So the merge can stash, e.g., distLeft/distRight onto a TopAndBottom wrap model (or distTop/distBottom onto a Tight/Through model) — sides those wrap elements can't legally express. The source values are valid (they come from wp:anchor), and this stays in the internal PM model rather than emitting bad XML here, so it's not a spec violation in the importer. But if that model round-trips back onto the wrap child on export, it would produce attributes the wrap element doesn't allow. Notably the new TopAndBottom test deliberately passes distL:'0', distR:'0' (the !== 0 guard skips them) — which sidesteps the case but doesn't prevent it for a real non-zero anchor distL/distR.

Suggestion (non-blocking): gate the merge per wrap type — left/right only for Tight/Through, top/bottom only for TopAndBottom, all four for Square — to keep the model aligned with each element's spec-allowed attributes.

The rest of the diff (layout-engine graphic-placement, floating-objects, layout-adapter mergeWrapDistancesFromPadding) is layout/geometry, not OOXML serialization, so it's outside the spec-compliance scope.

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

Hi @luccas-harbour! Visual testing regression must be addressed as well